PD 解耦架构

标签

AI/infra/推理引擎

AI/infra/调度

字数

2189 字

阅读时间

9 分钟

01-推理性能指标与瓶颈定位 的结论是：Prefill 是算力受限，Decode 是带宽受限 —— 两个阶段的瓶颈在相反的两侧。

把它们放在同一批里，就会出现两个问题：互相干扰，以及被迫共用一套资源与并行策略。PD 解耦（Prefill/Decode Disaggregation）就是把它们分到不同 GPU 上。

两个问题

DistServe（OSDI 2024，北大 + UCSD + StepFun）把动机讲得很清楚：

问题	内容
强 prefill-decoding 干扰	两阶段混在同一批里互相拖慢（长 Prefill 拉长同批 Decode 的 TPOT，机制见 03-推理调度：Continuous Batching 与 Chunked Prefill）
资源分配与并行策略被耦合	两阶段被迫用同一套配置，但它们的最优点在相反方向

第二点比第一点更根本。 应用往往分别强调两个阶段的延迟 —— Prefill 看 TTFT，Decode 看每个请求的 TPOT。在严格的延迟要求下，现有系统只能：

• 牺牲其中一个，或者
• 过度供给算力去同时满足两者

聚合与解耦的架构差别：

  聚合：两阶段混在同一批，共用一套资源与并行策略

    ┌────────────────── 同一批 GPU ──────────────────┐
    │  Prefill（算力受限）  ＋  Decode（带宽受限）      │
    │        │                        │               │
    │        └────── 互相干扰 ────────┘               │
    │  · 长 Prefill 把同批 Decode 的 TPOT 拉出尖刺      │
    │  · 被迫用同一套并行策略，而两阶段的最优点相反       │
    └─────────────────────────────────────────────────┘

  解耦：分到不同 GPU，各自最优

    ┌──── Prefill 池 ────┐          ┌──── Decode 池 ────┐
    │ 算力受限             │          │ 带宽受限            │
    │ 按 TTFT 要求调优      │  KV ───▶ │ 按 TPOT 要求调优    │
    │ 可以放新卡            │  传输    │ 可以放便宜的老卡     │
    └─────────────────────┘          └───────────────────┘
          ⇒ 消除干扰 + 独立调优        ⇒ 代价：净增一次 KV 传输

DistServe 的做法与结果

核心动作：把 prefill 与 decoding 计算分配到不同的 GPU，从而彻底消除干扰。

在此之上做三件事：

动作	内容
按阶段各自调优	给定应用的 TTFT 与 TPOT 要求，co-optimize 每个阶段的资源分配与并行策略
按带宽放置	根据服务集群的带宽决定两阶段摆在哪 —— 让解耦带来的通信最小化
优化目标换成 goodput	最大化「在 TTFT 与 TPOT 双约束下每 GPU 能服务的最大请求速率」

结果：

在多种主流 LLM、应用、延迟要求下，DistServe 能服务 7.4× 更多请求，或满足 12.6× 更紧的 SLO，同时 >90% 的请求保持在延迟约束内。

注意优化目标的措辞 —— 它优化的是在双约束下的最大速率，而不是「吞吐」或「延迟」中的任何一个。这正是 goodput 的定义（见 01-推理性能指标与瓶颈定位）。

Splitwise：连硬件也分开

Splitwise（ISCA 2024，Microsoft）的关注点不同 —— 它看的是阶段与硬件的匹配。

该文的两个观察：

prompt computation（Prefill）是 compute-intensive；token generation（Decode）是 memory-intensive。

Decode 阶段不需要最新 GPU 的算力 —— 它可以用更低功耗、更低成本的硬件来跑。

于是 Splitwise 把两阶段分到不同类型的机器上，并按三个目标分别优化集群设计：

目标	Splitwise 报告的结果
成本	1.4× 吞吐，同时成本低 20%
吞吐与功耗	同成本与功耗预算下，2.35× 吞吐

两阶段之间的状态转移（Prefill 算出的 KV Cache 要交给 Decode 机器）用 GPU 集群里的快速背板互联实现并优化。

这引出一条 DistServe 没强调的判断：解耦不一定要用同样的卡。把 Decode 放在便宜的老卡上、把 Prefill 放在新卡上，是解耦带来的额外自由度 —— 它把「选什么硬件」也变成了按阶段可优化的变量。

三种方案对照

方案	会议	核心主张	报告结果
DistServe	OSDI 2024	按阶段 co-optimize 资源与并行 + 按带宽放置	7.4× 请求数 / 12.6× 更紧 SLO
Splitwise	ISCA 2024	两阶段用不同硬件，各自最优	1.4× 吞吐且成本 -20%；或 2.35× 吞吐
TaiChi	—	聚合与解耦的统一框架（不预设哪种更好）	—

TaiChi 的定位值得记：它不去论证「解耦一定更好」，而是把「聚合」与「解耦」放在同一个框架里比较 —— 这与后面「什么时候不该解耦」一节是同一个问题。

KV 传输：解耦最核心的工程挑战

Prefill 机器算出的 KV Cache 必须搬到 Decode 机器。 这是解耦相对聚合净增的开销，也是它能不能成立的关键。

项	内容
传输量	与序列长度 × 层数 × KV 头数成正比 —— 可以用 10-KV Cache 与推理优化 的公式按目标模型算出来
传输后端	NVLink（机内）/ InfiniBand（跨机）/ RDMA —— 量级差异见 03-多卡互联与集群网络
工程抽象	vLLM 用 KV Connector 抽象传输后端，对接 NIXL / NCCL 等实现

这条决定了拆分点的选择：把两阶段放在高带宽域内能省传输开销，但会牺牲资源独立调优的自由度；放到跨机则相反。DistServe 说的「按集群带宽放置两阶段」，优化的就是这笔账。

解耦不是免费的

它换来的是「消除干扰 + 独立调优」，代价是「多一次 KV 传输」。这笔账划不划算取决于：

• KV 相对模型权重有多大 —— 长序列、大 KV 时传输量可观
• 两阶段之间的带宽有多高 —— 机内 NVLink 与跨机 IB 差一个数量级
• 负载是否偏斜 —— 请求的输入输出长度分布决定了 P/D 两池的配比（配比算错了，一池闲着另一池排队）

KV 传输量决定了拆分点选在哪：

  传输量 ∝ 序列长度 × 层数 × KV 头数
        （可按目标模型，用 KV Cache 的显存公式算出来）

  拆分点的两种取法：

    高带宽域内（机内 NVLink，900 GB/s）

      ┌───────── Prefill ────────┬───────── Decode ────────┐
      │        同一个 NVLink 域                            │
      └──────────────────────────┴─────────────────────────┘
      ⇒ 传输开销小；但两阶段挤在同一台机器上，独立调优的自由度受限

    跨机（InfiniBand，50 GB/s）

      ┌──── Prefill 池 ────┐  ──IB──▶  ┌──── Decode 池 ────┐
      │                    │           │                    │
      └────────────────────┘           └────────────────────┘
      ⇒ 资源可独立调优、可以放不同硬件；但传输量在窄链路上被放大

  ⇒ DistServe 说的「按集群带宽放置两阶段」，优化的就是这笔账

什么时候该用

判据来自它的优化目标：严格的双延迟约束（TTFT 与 TPOT 都要满足）。

该考虑解耦	不必解耦
对 TTFT 与 TPOT 同时有严格 SLO	只关心吞吐，延迟约束宽松
长 Prompt 与长生成混合的负载（干扰最严重）	Prompt 都很短（Preplit 本身不构成尖峰）
能做 P/D 分池的规模化部署	单机小规模（拆分后传输开销占比过高）
输出长度分布可预测（好定配比）	输出长度方差极大（配比难定）

先试的手段在它前面：Chunked Prefill 已经能显著缓解 Prefill 对 Decode 的干扰（见 03-推理调度：Continuous Batching 与 Chunked Prefill）。只有当「缓解干扰」不够、还需要「两阶段独立调优资源与并行策略」时，解耦的价值才真正兑现 —— 那一层是调度技巧解决不了的。

相关

• 01-推理性能指标与瓶颈定位 —— 两阶段瓶颈相反、goodput 的定义
• 03-推理调度：Continuous Batching 与 Chunked Prefill —— 缓解干扰的第一层手段
• 10-KV Cache 与推理优化 —— 被传输的那份 KV 有多大
• 03-多卡互联与集群网络 —— KV 传输的带宽约束
• 06-vLLM 部署、参数与服务特性 —— 生产侧的部署与运维

参考

• https://www.usenix.org/system/files/osdi24-zhong-yinmin.pdf
• https://arxiv.org/abs/2311.18677
• https://arxiv.org/abs/2403.02310
• https://docs.vllm.ai/en/latest/features/disagg_prefill.html
• AIInfraGuide. 推理优化 · 阶段解耦章节大纲.

源站只有大纲、没有正文。本笔记按 DistServe / Splitwise 两篇论文的一手数据补全，TaiChi 部分未逐条核实

贡献者

YJ

文件历史

最后编辑于 5 分钟前查看完整历史

7864e-111

aa2e3-docs：补充

ae1ee-docs：内容完善

04687-docs：笔记